By way of background, wireless networks have been in use in the public safety sector, (police, fire fighters, emergency workers, etc.) for a long time. For example, in the United States, the standard of public safety wireless network is the APCO (Association of Public Safety Communications Officials) Project 25 (P25) Systems, whose specifications are the responsibility of the Telecommunications Industry Association (TIA), standard committee TR-8. The P25 standard is an international standard with systems deployed in over 40 counties.
FIG. 1 shows an embodiment of a high level architecture of a P25 system. The local network may consist of any number of base stations (shown as 110 and 120), referred to as sites in P25 terminology. A plurality of subscriber wireless communication devices (shown as 101-104) are connected to the base stations through the air interface. The base stations are connected to a collection of controlling modules referred to collectively as the radio frequency sub-system (RFSS) 126. In P25, two relevant functional modules are the call control module 122, which handles call signaling, and the media control module 124, which deals with the forwarding and processing of media (e.g., voice) traffic. Attached to the RFSS are peripherals such as a dispatch console 128, one or more databases 130, one or more data terminals 132, and one or more gateways 134 to other networks such as the public switched telephone network (PSTN) 136. An Internet Protocol (IP) network 138 couples the RFSS 126 to other RFSSs.
Group Calls and Push to Talk (PTT)
One of the most important applications for a public safety wireless network is a group PTT call, i.e., a call in which one member of the group can speak to all other members simultaneously. For example, all police officers on patrol could constitute one group. In order to facilitate communications in an orderly manner, a floor control mechanism is needed to arbitrate who should generally speak in the event two and more members request to speak at the same time. As is known, a PTT user who wants to speak to the group will generally push a button on the person's handset. A message would then be sent to the RFSS, which will generally arbitrate all the talk requests and either grant or deny each request by sending a response back to the requestors.
The Inter RF Sub-System Interface
The public safety sector has recognized the need of connecting different RFSSs together to form a larger network with a much larger coverage. Based on this need, the TIA TR8 committee has developed such a standard, referred to as the Intra-RF Sub-Systems Interface (ISSI). This specification is based on IP for the transport of information. The call signaling protocol is based on the Session Invitation Protocol (SIP, RFC 3261), while the voice traffic and push-to-talk control messages are carried through the use of the Real Time Protocol (RTP), RFC 3550). The ISSI specifies the connection between the RFSSs. The over-the-air interface protocol is specified by another suite of standards.
With the ISSI a group can span multiple RFSSs. One RFSS would be designated the home RFSS, which will generally manage all the activities of the group. The floor-arbitrate function of the group also resides at the home RFSS. The non-home RFSSs are referred to as serving RFSS and are connected to the home RFSS through RTP. Members of a group do not need to be attached at the home RFSS; that is, they can roam to another RFSS. When a user of the group requests the floor, then the serving RFSS forwards the request to the home RFSS using the ISSI. The home-RFSS will generally arbitrate any received requests and award the floor to a “winning” user. In addition to floor arbitration, the home RFSS also receives voice traffic from a serving RFSS and forwards it to other RFSSs. Specifically, the ISSI supports the following functions for group calls.
When a user at a serving RFSS indicates that it would like join a group, the serving RFSS registers the user with the home RFSS, indicating that there are one or more users at its location joining the group. The SIP REGISTER message may be used to accomplish this registration process.
Voice traffic and PTT control messages are conveyed using RTP. ISSI specifies procedures to set up RTP connectivity between home RFSS and serving RFSSs. The SIP protocol suite is used to signal the RTP set up. In order to conserve network resources, after an extended period of inactivity, the home RFSS may tear down the RTP connections between it and the serving RFSSs. During this period, the serving RFSSs remain registered with the home RFSS. When the call becomes active again, the home RFSS or the serving RFSS can trigger call set up to re-establish the RTP connectivity again.
ISSI provides a set of control messages to support push-to-talk. These messages are encoded as part of the RTP messages.
Voice traffic is also carried as part of the RTP payload. RTP connectivity is generally established before PTT control messages and voice traffic can be sent between the home RFSS and the serving RFSSs.
PTT Control in ISSI
ISSI supports various Pit control messages, including, but not limited to, the following:                PTT-transmit-request: A message sent from a serving RFSS to the home RFSS requesting the floor on the behalf of a user.        PTT-transmit-grant: A message sent by the home RFSS to a serving RFSS granting a request from that serving RFSS.        PTT-transmit-deny: A message sent by the home RFSS to a serving RFSS denying a request from that serving RFSS.        PTT-transmit-start: A message sent by the home RFSS to all serving RFSS, except the serving RFSS that has been granted the floor, indicating that the floor has been grant to a user at another RFSS. These RFSSs should generally be prepared to receive traffic.        PTT-transmit-wait: A message sent by the home RFSS to a serving RFSS which has just requested the floor. This message indicates that the home RFSS is processing the request, but the processing may take some time such as when enhanced functions are required.        PTT-transmit-mute (and PTT-transmit-unmute): These messages can be sent by all RFSSs to mute (or unmute) a transmission temporary such as because of resource problems.        PTT-heartbeat and PTT-heart_query: These messages ascertain the RTP connectivity between RFSSs.        
FIG. 2 is an illustration of a call flow for PTT over ISSI. In FIG. 2, an RFSS 200 represents the home RFSS of a talk group. Connected to the home RFFS 200 are various serving RFSSs 210, 220, and 230. Various users (SU) 212, 222, and 232 are connected to these RFSSs, respectively. In this example, it is assumed that RTP connectivity between the home RFSS and the serving RFSS has already been set up. The sequence of events is described below.
In this example, a first user (SU 212) and a second user (SU 222) both want to speak to the floor. They press a button at the handset at about the same time. By pressing the button, the handset typically generates a Group-voice-request (GRP_V_REQ) message to their respective serving RFSS (210 and 220) over-the-air interface. They are shown as messages 1 and 1′.
The serving RFSS 210, upon receiving the GRP_V_REQ message from the first user (SU 212), typically generates a PPT-transmit-request message to the home RFSS. The PTT message is one of the push-to-talk control messages encoded as an RTP packet, as specified in the ISSI specification. It is assumed that the first user (SU 212) is the only SU to request the floor at the serving RFSS 210. If there is more than one SU at RFSS 210 requesting the floor, the serving RFSS 210 typically determines a local winner, based on the priority of the request as well as the local policy. The PTT-transmit-request message includes the identity of the first user (SU 212), the subscriber requesting the floor. Similar events take place at RFSS 220. The PTT-transmit-request messages are shown as messages 2 and 2′.
The home RFSS, upon receipt of the two PTT-transmit-request messages from the RFSSs 210 and 220, will typically decide who would win the floor. In this example, it is assumed that the first user (SU 212) is the floor winner. Upon deciding that the second user (SU 222) is the floor winner, the home RFSS 200 will generally: (1) Send a PTT-transmit-deny message (message 3) to the serving RFSS 210 informing it that its request for SU 212 has been denied; (2) send a PTT-transmit-grant message (message 4) to RFSS 220 indicating that SU 222 has been awarded the floor; and (3) send to PTT-transmit-start message (message 6) to all RFSSs except the RFSS of the floor winner, i.e., RFSS 220.
Both the PTT-transmit-grant and the PTT-transmit-start messages contain the identity of the floor winner. Both messages, upon arrival at the serving RFSS, will generally cause the generation of Group-voice-grant (GRP_V_GRANT) (messages 7 and 7′) over-the-air to all members of the group connecting to the RFSS. Through these messages, other members of the group are informed that the first user (SU 210) is awarded the floor and that each should generally prepare to receive speech from it.
Structure of Over-The-Air Voice Traffic for P25
P25 uses the IMBE vocoder, which encodes one 20 millisecond segments of speech one at a time. The output is then encoded as a voice frame. The IMBE may group 18 of such frames into a super frame, as shown in FIG. 3. The first 9 voice frames of a super frame 302 are collectively referred to as data (or logical) unit 1 (304), while the last 9 frames are collectively referred to as data (or logical) unit 2 (306). When transmitting over-the-air, other types of traffic are typically multiplexed with the voice frames, such as the link control word (LC), low speed data (LD), and encryption sync word (ES).
The link control word (LC) field contains information such as Manufacturer ID, Talk group ID or destination ID, Source ID, and/or Emergency indication.
The low speed data (LD) field allows the sender to send a very small amount of data with the voice traffic if needed. The field is only 4 octets (1 octet=8 bits) long for each super frame (360 milliseconds), result in a bit rate of 88.89 bits per second.
The encryption sync word (ES) field contains information so that the next super frame of voice traffic can be decrypted. The message indicator contains the encryption initialization vector for the next super frame. The algorithm ID specifies the encryption algorithm used. The key ID which specifies the key used in encryption.
In order to operate in a noisy environment, the voice traffic (as well as the LC, LD, and ES fields) is encoded with forward error correction codes (both the Golay code and the Hamming Code) so that some amount of errors in transmission can be corrected.
At the beginning of a talk spurt, the voice traffic is preceded by a header work, which contains information such as the message indicator, the algorithm ID, and the key ID as in the ES word (this information is used by a receiver to decode the first super-frame), the manufacturer ID, and/or the talk group ID.
LTE
The 3rd Generation Partnership Project (3GPP) initiated the Long Term Evolution (LTE) project in 2004 to address its next generation wireless technology and architecture. Initial specifications of LTE appear as release 8 of the 3GPP family of specifications. LTE provides a number of improvements/enhancements to the current 3rd generation systems, such as spectral flexibility (i.e., the technology can operate over 1.4, 2.5, 5, 10, 15 and 20 MHz channels), high spectral efficiency (i.e., the technology has a high bit rate per Hz, which couples with the ability to support high bandwidth result in high data rate, whereby for a 20 MHz channel the downlink is 100 Mbps while the uplink is 50 Mbps), flexible cell size (i.e., cell size can be from 5-100 km, reduced latency, all IP architecture (i.e., the architecture is IP based which enables easy deployment of services such as video, voice, web access, etc. and also allows simpler inter-working with other fixed and mobile networks), open interface for inter-working (i.e., provides open interfaces to inter-work with existing technologies, and QoS support.
LTE System Architecture
An exemplary LTE architecture is illustrated in FIG. 4. The major components of the systems include, but are not limited to, at least one user equipment (UE) 402, at least one evolved node B (eNodeB) 404, at least one Mobility Management Entity (MME) 406, at least one serving gateway (S-GW) 408, at least one PDW Gateway (P-GW) 410, at least one Policy and Charging Rule function (PCRF) 412, and at least one Home Subscriber Server (HSS) 414.
The evolved node B (eNodeB) 404 is the base station in LTE.
The Mobility Management Entity (MME) 406 handles the authentication of the UE 402 when it first attached to the LTE network. It also handles the signaling for bearer setup, modification, and tear-down. It also manages roaming of the UE 402.
The serving gateway (S-GW) 408 acts as mobility anchor for inter-eNodeB handover. Multiple eNodeBs 404 can be connected to an S-GW 408. As the UE 402 roams from each eNobeB 404 that is attached to the same S-GW, packets from/to the UE 402 will generally go through the same S-GW (thus the term anchor point). LTE specifies the interface between eNodeBs 404 (the X2 interface) to support smooth hand-off. As a reference, the S-GW 408 typically can support an area the size of 2-3 states.
The PDW Gateway (P-GW) 410 provides interfaces to other IP networks and serves as the global mobility anchor for the UE. Multiple S-GWs can be connected to the P-GW 410. In border areas, it is possible that the UE 402 roams from one S-GW to another S-GW. In this scenario, all packets will generally still go through the P-GW 420 (and thus the term global anchor point).
The Policy and Charging Rule Function (PCRF) 412 supports per session QoS and associated billing. The PCRF 412 will generally accept requests from external servers to setup bearers with the appropriate QoS supports in the LTE network. When the UE 402 requests a bearer setup, the P-GW 410 will generally forward the request to the PCRF 412 for approval.
The Home Subscriber Server (HSS) 414 maintains the user profiles. If the network operator also deploys an IP Multimedia Subsystem (IMS) 416, the HSS 414 can be shared between the LTE network and the IMS 416.
Note that the standard also specifies connections between multiple eNodeBs, MMEs, and S-GWs connecting among themselves (not shown in FIG. 1).
LTE Bearer
In LTE, the UE 402 will generally send and receive user packets through its designated PDN-GW. The data path between the UE and the PDN-GW 410 will generally go through the eNodeB 404 and the S-GW 408. (The data path is shown as solid lines in FIG. 3; the dotted lines are paths for signaling messages.) The PDN-GW 410 will then forward the data packet to its intended destination. It also accepts packets on the behalf of the UE 402, and then forwards the arriving packets to the UE 402.
The logical connection between the UE 402 and the PDN-GW 410 is referred to as the EPS (Evolved Packet System) “bearer” (or bearer for short). Associated with each bearer is a QoS (Quality of Service) profile which governs how packets of this bearer should generally be treated by the network. As the UE 402 may have multiple concurrent sessions, each with a different QoS needs, multiple bearers can be set up between an UE 402 and the PDN-GW 410, each supporting a different grade of QoS. Multiple sessions of the same QoS class can be mapped onto the same bearer.
When an UE 402 is first attached to the network, a default bearer, with a prescribed QoS, will generally be set up between the UE 402 and the PDN-GW 410. Other bearers, often referred to as dedicated bearers, can be set up and torn down on an as needed basis.
Resource Allocation and Scheduling
Residing in the eNodeB 404 is a scheduler, which manages the resource allocation for both upstream and downstream traffic. In the downstream direction, the eNodeB 404 receives data packets from the S-GW 408. Based on the quality class indicator (QCI), guaranteed bit rate (GBR), and maximum bit rate (MBR) of the bearers, and/or the bandwidth of the air link, the scheduler may determine when a packet will be forwarded downlink to the UE 402. For example, for a guaranteed bit rate (GBR) bearer, the eNodeB 404 should generally reserve sufficient resources so that, if the traffic load of the incoming packets for the bearer is less than or equal to its GBR, the packet would be forwarded with little delay. For non-GBR bearers, it is possible congestion could occur and the packets will generally be buffered at the eNodeB incurring some delay. In extreme cases packets may be discarded.
Data is transmitted in frames in LTE. A frame contains a number of resource blocks which are the basic information units. Embedded in the downlink channel are the Physical Downlink Control Channels (PDCCH). A PDCCH carries the DCI (Downlink Control Information), which includes the resource assignments for the UE 402 or group of UE. By monitoring the PDCCH, the UE 402 could determine whether a particular downlink frame contains information for it or not.
In uplink, when the UE 402 has data to send, it will generally first send either a Scheduling Request (SR) or Buffer Status Reports (BSR) to the eNodeB 404. The SR is sent using the Physical Uplink Control Channel (PUCCH), while the BSRs are sent using resource blocks that are assigned to the UE for uplink transmissions. If needed, the UE 402 can use the random access procedure to request an allocation to send a BSR. One or more BSR messages can be piggybacked with user data packets if they fit. Based on the QCI, GBR, MBR of the bearer and the amount of data buffered at the UE's transmitter, the eNodeB 404 typically determines when the UE 402 should generally transmit (and how much). This decision is conveyed as a DCI message over the PDCCH channel as described previous. The above process is often referred to as dynamic scheduling (DS), since the UE 402 is requesting resource allocation at an on-demand basis.
For many GBR applications, such as voice over IP (VoIP), data is transmitted at regular intervals (e.g., one voice packet every 20 milliseconds for most VoIP applications). If dynamic scheduling is used, every 20 milliseconds for the uplink, there will generally be an upstream service request, followed by a grant, and then the transmission of the user data. For the down link, there will generally be a downlink DCI message every 20 milliseconds, indicating the downlink resource allocation. This is inefficient as there are many signaling messages (2 per 20 milliseconds). Therefore, LTE supports another type of scheduling, persistent scheduling (PS), to support these applications. In PS, when the eNodeB allocates to UE the initial resource block for both uplink or downlink transmission, it also implicitly allocates subsequent resource blocks, at regular intervals as indicated by the application. This avoids all subsequent signaling messages between the UE 402 and the eNodeB 404 for this bearer.
Silence Suppression and Semi-Persistent Scheduling
LTE supports voice calls, among other things. In a conversational voice call between two individuals, usually only one person will generally speak at a time. The other person will generally just be listening. Therefore, to be bandwidth efficient, most voice codecs, such as the Adaptive Multi-rate (AMR) coder from 3GPP, support silence detection. The codec has the capability to detect silence period when a person is not speaking (and even during silence periods within a talk spurt). When the codec detects a silence period, the codec will generally not generate voice packets thus saving bandwidth. During the silence period, the codec may send silence insertion descriptors (SID) every so often, but at a much slow rate than regular voice packets. The SID packets describe the nature of the background voice (such as noise level) so that the receiver can reproduce the background environment more accurately. For AMR, regular voice packet is sent once every 20 ms, while SID packets are sent once 160 milliseconds. For conversation voice, the silence period of a typical call is about 58% on the average (i.e. an activity period of about 42%). Therefore, there is substantial saving in bandwidth if silence suppression is used, and consequently, more calls can be admitted.
When silence suppression is enabled in a codec, persistent scheduling would not be every efficient. Consider the AMR codec as an example. During a silence period, SIDs are transmitted once every 160 milliseconds. However, with PS, resource slots are allocated every 20 milliseconds for the transmission of regular voice packets. Therefore, 7 out of 8 resource blocks are wasted during the silence period. Because of this, LTE also supports another form of scheduling, i.e., semi-persistent scheduling (SPS). In SPS, when the user at the UE 402 wants to speak, the UE 402 will generally send an SR to the eNodeB 404. The eNodeB 404 will then grant the UE's initial request just as in the case for PS. In the example for AMR, a transmission slot is granted implicitly every 20 milliseconds. When the UE 402 enters a silence period, it will generally stop transmitting voice packets to the eNodeB 404. When the eNodeB 404 detects that there are a number of consecutive empty slots (e.g., 2 or 3 slots), it will generally assume that the UE 402 has entered a silence period. The eNodeB 404 can then release the subsequent implicitly assigned slots and allocate them to other users if needed. When the UE 402 needs to send a SID, it will generally send a service request (SR) to the eNodeB 404 using dynamic scheduling (DS). The UE 402 would only request sufficient resources to transmit the SID packet. When the UE 402 wants to transmit the next SID packet (160 milliseconds later for AMR) it will generally send another SR to eNodeB 404 again using DS. When the user at the UE 402 speaks again, the UE 402 will generally then send an SR to the eNode 404 starting SPS.
Public Safety Sector and LTE
Public safety agencies realize the important of deploying multimedia applications, such as streaming video. The current public safety wireless networks, such as the P25 systems as described above, are narrow band systems and lack the speed to support these applications (e.g., each channel in P25 operates at 9.6 Kbps). Therefore, public safety agencies are interested in deploying broadband wireless networks to support these new applications. LTE represents a technology that may be used. Deployment of mission critical PTT services over these broadband networks will generally be a natural development.
ISSI Over P25
When considering deploying PTT services over LTE, a concern is the interoperability between the PTT services over the LTE network and the PIT services of the P25 network. For example, one would like the ability of a talk group spans over both networks. One approach is to use ISSI as the basis for the PTT protocol for the LTE network.
One approach is illustrated in FIG. 5. The system shown in the figure includes a PTT server (identified as ISSI/LTE GW 500 in FIG. 5), one or more UE 502, at least one eNobeB 504, at least one SGW 506, at least one MME 508, at least one HSS 510, at least one PGW 512, at least one PCRF 514, one or more P25 base stations 516, at least one dispatch console 518, at least one console subsystem 520, and at least one RFSS 522.
In this approach, PTT is supported through the PTT server 500. By way of example, suppose the UE 502 wants to invoke the PTT services. It would first establish an EPS bearer to the P-GW 512. This bearer would support the SIP signaling between the UE 502 and the server 500 using the procedures as specified in the ISSI for both authentication and call set up. When joining a talk group, the UE 502 (or the server 500) would set up an RTP connection to convey voice packets between the two. The RTP connection will generally operate over another EPS bearer, which is set as a result of the SIP signaling. Although the protocol is the same as specified in the ISSI specification in most respects, there is at least one difference. In the formal specification, the ISSI protocol is between two RFSSs. In this usage, the protocol is between a RFSS-like server and the user equipment. Thus, the behavior of the server would be slightly different. For example, when the server receives voice packets from the UE, it will generally forward the packets to all other UEs belonging to the same talk group that is attached to it, in addition to other servers. In that case, the protocol between the server and the UEs may be referred to as ISSI-UE.
The server 500 can be connected to other P25 RFSSs 522 using the ISSI. In FIG. 5, it is shown as being connected to RFSS 522. Although, in FIG. 5, only one P25 RFSS 522 is shown connected to the server 500, multiple RFSSs can be connected to the server 500. From the view point of the P25 RFSS 522, the server 500 behaves exactly like another RFSS.
There are a number of approaches to support PTT over an IP-based wireless network. However, they all are consumer oriented. The advantages listed below are the advantages of ISSI/LTE when compared to these other approaches for public safety. For instance, talk groups can be homed at either the LTE network or the P25 network and user devices with dual radios (LTE and P25) can roam from one network to another. The system can leverage all the support systems that are already in existing in the P25 network. For example, the console sub-system in the P25 can be used to support UE that are attached to the LTE network. Also, the key management system in the P25 network can be used to manage the group key for UEs that are attached to the LTE network. Interoperability for PTT between the two networks would be simpler as the protocol over the LTE network is ISSI based.
In dynamic scheduling the UE (User Equipment) will generate a service request when it has a packet to transmit. For voice, a packet is transmitted every 20 milliseconds. Thus, the UE will generally request a transmission every 20 milliseconds. This is inefficient in terms of the usage of the MAC layer signaling channel. One way to reduce the signaling request is to use persistent signaling (PS) and/or semi-persistent (SPS) signaling. In PS and SPS, a fixed amount of resource is allocated at every 20 milliseconds (or other periodic intervals). With this pre-allocation, the UE does not need to send a service request every 20 milliseconds and thus the number of signaling messages are greatly reduced.
In a system that uses ISSI over LTE it is likely that there will generally be unused bandwidth when transmitting voice packets, if PS or SPS is used. This inefficiency arises for a number of reasons.
The ISSI voice packets are of unequal length as some of them carry other information in addition to voice. Given that the resource allocated is fixed but the packet is of variable size, with PS or SPS, the allocation must support the maximum packet size. Therefore, there is spare bandwidth for some packets.
Thus, there is a need for a method and system that utilizes this spare capacity to transfer data.